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USE  OF  THE  USER  ACTION  NOTATION  AT  THE  NAVAL  RESEARCH 
LABORATORY  HUMAN-COMPUTER  INTERACTION  LABORATORY 


Purpose  of  Visit 

Mr.  Joe  Chase,  a  PhD  Candidate  in  the  Department  of  Computer  Science  at  Virginia  Tech, 
spent  two  weeks  during  Summer  1993  (18-  30  July)  in  the  HCI  Laboratory  of  the  Naval 
Research  Laboratoiy.  The  purpose  of  this  visit  was  threefold:  to  introduce  researchers 
in  the  Information  Technology  Division  of  the  Naval  Research  Laboratory  (NRL)  to  the 
User  Action  Notation  (UAN),  a  notation  for  representing  the  design  of  the  interaction 
component  of  interactive  software  systems;  to  use  the  UAN  in  describing  a  variety  of 
unique,  innovative  interaction  techniques  to  evaluate  the  notation  for  its  ability  to 
represent  such  techniques;  and  to  explore  possibilities  for  future  research  and 
technology  transition  with  the  UAN  collaboratively  between  NRL  and  Virginia  Tech. 

The  first  of  these  goals,  introducing  NRL  researchers  to  the  UAN,  was  accomplished  in 
three  ways.  An  overview  introduction  to  the  UAN  as  a  notation  and  a  method  for 
interaction  development  was  presented  on  7/27/93.  This  presentation  was  followed  by 
a  2  hour  discussion,  including  approximately  a  dozen  people,  about  the  UAN  and  its 
application.  The  draft  version  of  a  UAN  tutorial  was  described  as  a  means  for 
researchers  to  reference  information  about  the  UAN.  A  UAN  description  for  an 
existing  system  at  NRL,  the  Damage  Control  Information  System  (DCIS),  was  developed 
to  provide  an  example  of  the  potential  role  of  the  UAN  in  the  analysis  of  existing 
interfaces  as  well  as  for  future  design. 

The  second  goal,  evaluating  the  UAN,  especially  with  respect  to  innovative  interaction 
techniques,  was  accomplished  in  two  ways.  The  DCIS  system  was  described  using  the 
UAN.  TTiis  provided  a  sample  UAN  description  for  future  reference.  UAN  descriptions 
of  the  basic  task  of  using  a  device  for  a  variety  of  the  unique  interaction  techniques 
available  at  NRL  were  also  developed. 

The  third  goal  of  this  visit  was  to  identify  areas  of  future  research  and  technology 
transfer  between  NRL  and  Virginia  Tech.  NRL  provides  a  unique  opportimity  for 
human-computer  interaction  research  and  application  because  of  its  focus  on  the 
transfer  of  technology  and  ideas  from  academia  to  application.  Being  able  to  observe 
and  interact  with  researchers  at  NRL,  as  well  as  being  able  to  experiment  with  new 
interaction  techniques,  has  allowed  us  to  identify  a  number  of  outstanding  issues 
which  require  Either  study.  Ihese  issues  include,  but  are  not  limited  to,  the 
relationsUp  between  the  UAN  and  virtual  reality  devices  and  the  examination  of 
device  vocabularies  as  a  way  of  approaching  new  interaction  techniques. 


The  User  Action  Notation 

The  User  Action  Notation  (UAN)  is  a  user-  and  task-oriented  notation  that  describes  the 
behavior  of  a  user  and  an  interface  during  their  cooperative  performance  of  a  task 
(1).  The  primary  abstraction  of  the  UAN  is  a  user  task  -  a  user  action  or  group  of 
temporally  related  user  actions  perfonned  to  achieve  a  work  goal.  A  user  interface  is 
represented  as  a  quasi-hierarchical  structure  of  asynchronous  tasks,  sequencing 
within  each  task  is  independent  of  that  in  the  others.  User  actions,  corresponding 
interface  feedback,  and  state  information  are  presented  at  the  lowest  level.  Levels  of 
abstraction,  where  lower  level  tasks  are  combined  under  a  single  general  task  name, 
are  used  to  hide  these  details  and  represent  the  entire  interface.  At  all  levels,  user 
actions  and  user  tasks  are  ordered  and  combined  using  temporal  relations  such  as 
sequencing,  interleaving,  and  concurrency.  Since  textual  notations  are  not  always 
convenient  for  specifying  sdl  components  of  an  interface,  the  UAN  includes  screen 
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pictures,  or  scenarios,  and  can  be  supplemented  with  state  transition  diagrams  to 
indicate  precisely  how  the  user  interacts  with  the  interface.  The  following  example 
shows  the  UAN's  hierarchical  and  temporal  approach  to  the  description  of  a  user 
interface. 

As  an  example,  consider  a  simple  calendar  management  system.  We  assume  systems 
and  requirements  analysis  have  determined  that  the  user  wants  to  perform  five  basic 
tasks:  viewing,  adding,  modifying,  and  deleting  an  appointment  on  the  calendar,  and 
setting  an  alarm  associated  w'ith  a  given  appointment.  Our  first  step  would  be  to 
specify  the  hierarchical  relationships  at  this  highest  level  (Figure  1). 


Figure  1.  Highest  level  of  hierarchy  for  calendar  management  system 


However,  having  specified  the  hierarchical  decomposition  of  tasks,  we  must  now 
specify  temporal  relationships  among  these  user  tasks  (Figure  2). 


[Task:  manage  calendar 

User  Action 

Feedback 

Interface  State 

OR(add  appointment, 
view  appointment, 
modify  appointment, 
delete  sq>pointment, 
set  alarm  )* 

Hgure  2.  Highest  level  of  abstraction  for  calendar  management  system 


In  Hgure  2,  OR  indicates  that  the  user  may  choose  any  one  of  the  five  tasks  that  follow. 
The  asteri^  (*)  after  the  disjunction  indicates  that  the  user  may  perform  this  choice 
zero  or  more  times.  (We  borrow  this  notation  from  the  Kleene  star  closure  operator  of 
formal  language  theory;  the  UAN  also  provides  a  plus  (-i-)  operator  to  indicate  that  an 
action  must  be  performed  one  or  more  times.)  Thus,  Ae  UAN  description  in  Figure  2 
specifies  that  the  user  can  perform  a  sequence  of  tasks  of  any  length  (including  zero), 
with  eadi  task  selected  independently  firom  those  specified  in  the  disjunction.  Each  of 
these  tasks  could  Aen  be  decomposed  further  using  the  same  process. 


2 


The  UAN  is  primarily  a  notation  for  behavioral  representation  of  an  interaction 
design.  However,  through  empirical  work  with  industrial  users  of  the  UAN,  we  have 
found  that  it  has  a  variety  of  uses  across  the  entire  interaction  development  process. 
As  we  continue  to  collect  information  on  how  the  UAN  is  being  used,  a  composite, 
seamless  method  of  organization,  representation,  and  communication  has  emerged. 
This  method  and  the  basic  symbols  of  the  UAN  are  fully  described  in  a  UAN  Tutorial 
(2).,  and  will  not  be  detailed  in  this  document.  However,  for  reference.  Appendix  2 
contains  a  summary  of  the  most  frequendy  used  UAN  symbols.  For  the  reader  who  is 
completely  unfamiliar  with  UAN,  we  recommend  obtaining  the  UAN  Tutorial  from 
Virginia  Tech. 

We  have  found  the  UAN  to  be  useful  both  during  the  design  process  and  as  a  reverse 
engineering  tool  for  existing  user  interfaces.  The  method  of  application  of  the  UAN  is 
very  similar  in  both  cases  as  will  be  described  in  more  detail  in  the  next  section. 


A  UAN  Example:  The  Damage  Control  Information  System 

A  Damage  Control  Information  System  (DCIS)  has  been  developed  in  the  Information 
Technology  Division  at  NRL  DCIS  provides  the  user  with  the  ability  to  monitor  (and  in 
some  cases  control)  various  damage  control  apparati  throughout  a  ship  from  one 
central  location.  This  system  monitors  smoke,  heat,  flood,  and  flame  detectors,  and 
allows  monitoring  and  control  of  alarms,  fire  main  >^ves,  fire  main  pressure  gauges, 
and  fire  pumps.  The  user  interface  to  DCIS  provides  a  user  with  direct  manipulation 
control  over  a  representation  of  the  physical  object  which  they  are  tiying  to  manage. 

The  purpose  of  writing  a  complete  UAN  description  of  DCIS  was  not  to  critique  its  user 
inteiface  but  rather  to  evaluate  the  abilities  of  the  UAN  to  describe  this  type  of 
interface  and  to  provide  an  example  for  future  reference.  The  UAN  provides  a  Clew  of 
the  interaction  which  helps  to  point  out  aspects  of  the  interaction  design  that  may 
have  previously  gone  unnoticed.  The  UAN  typically  is  used  as  a  design  representation 
technique  as  an  interactive  system  is  being  designed.  The  process  of  developing  UAN 
descriptions  is  similar  whether  they  are  being  written  for  a  new  user  interface  or  for 
an  existing  interface. 

The  first  step  in  the  process  of  applying  the  UAN  to  an  existing  interface  design  is  to 
d^elop  a  hierarchical  decomposition  of  tasks  in  the  user’s  problem  domain.  This  can 
be  done  either  by  interacting  with  the  interface  or  prototype  if  it  has  been  developed 
or  throu^  analysis  of  design  documents  if  the  interface  is  still  in  the  design  phase. 
For  example,  in  the  case  of  DCIS,  the  user’s  global  task  of  managing  damage  control 
activities  was  decomposed  into  four  tasks  as  shown  in  Figure  3.  These  tasks  were 
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Hgtire  3.  First  level  of  decomposition  of  DClS  tasks 


Each  of  these  tasks  can  then  be  further  decomposed  until  at  some  point,  all  the  user’s 
problem  domain  tasks  have  been  decomposed  as  much  as  possible.  A  complete  UAN 
description  of  the  DClS  is  given  in  Appendix  1.  If  we  were  designing  a  new  system,  we 
cotild  have  reached  this  point  without  making  any  implementation  decisions.  For  a 
new  system,  it  would  be  useful  at  this  point  to  define  the  interaction  platform,  i.e., 
devices,  buttons,  techniques,  etc.  Whether  for  a  new  system  or  as  in  this  case  for  an 
existing  system,  these  interface  objects  and  groups  of  objects  can  be  represented  by 
definitions  that  describe  the  objects  and  their  behavior.  Some  examples  of  object 
definitions  from  DClS  are  shown  in  Hgure  4. 


Definitions: 

Qass:  buttons 

Description:  Directs  appearing  on  the  screen  that  look  ttuee 
dimroional 

Highlighfbig:  buttons  appear  two  dimensional  (!) 

Group:  tpggle  buttons 

Des^ption:  bi>state  button  tfuit  change  state  on  selection 
Highlighting:  butttms  show  inverse  video  (!).  Button  text 
aho^  inverse  state  (!0« 

Mennbers:  AM/FM 

Gtoiqx  default  buttons 

Description:  rectangular  buttons  that  cxmtrol  d^ult 
configuration  ^  mains 

(BghUghtir^  buttons  become  slighfiy  darker  on  mouse  down 

(!) 

Members:  Xray,  Yoke,  Zebra _ 


Hgure  4.  Sample  object  definitions  from  DClS 
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These  object  definitions  then  lead  us  to  develop  articulation-level  macros  that  operate 
on  these  objects  (e.g.,  select  button).  The  articulation  level  is  the  level  in  a  UAN 
description  at  which  the  user  is  actually  using  an  input  device  to  accomplish  some 
task.  This  is  the  level  at  which  inconsistencies  in  user  interaction  design  are 
discovered.  This  is  done  by  creating,  either  from  scratch  or  through  examination  of 
an  existing  interface,  generic  macros  such  as  select,  etc.  If  we  discover  that  similar 
objects  have,  for  example,  different  behavior  for  the  same  user  actions,  or  the  same 
behavior  for  different  user  actions,  then  we  have  discovered  inconsistency.  Figure  5 
shows  an  example  from  DCIS  where  two  similar  objects  are  behaving  very  differently 
under  the  select  task. 


Task:  Select  Pressure  Gauge(pressure  gauge) 

Arena:  multiple 

User  Action 

Feedback/ 

Presentation 

Interface  State 

~[pressure  gauge  icon] 

Mv 

pressure  gauge  iconi 

selected  >  pressure 
gauge 

activated  -  pressure 
gauge 

Task:  Select  Detector(button) 

Arena:  multiple 

User  Action 

Non-Mainline 

Action 

Feedback/ 

Presentation 

Interface  State 

button  icon! 

selected  »  button 

■■■■■■■ 

mimiiiiiiiiiiiiiiiim 

~[x,y]  not  in  button 
icon 

button  icon-! 

DbiydiidiUiujnHii 

button  iconi 

button  icon-1 

activated  *  button 

~[x,y]  not  in  button 
icon 

button  icon-I 

Ml 

activated  «  none 
selected  -  none 

Hgure  S.  Sample  select  tasks  from  DCIS  showing  behavioral  inconsistencies 


To  briefly  ecplain  the  UAN  notation  shown  in  these  examples,  in  the  first  cell  of  the 
User  Action  column  of  the  first  example,  ^[pressure  gauge  icon]  means  "move  the 
cursor  (~)  to  the  pressure  gauge  icon  and  depress  the  mouse  button  (Mv)".  In  the 
Feedback/Presentation  column  associated  with  this  user  action,  pressure  gauge  iconi 
means  highlight  (|)  the  pressure  gauge  icon.  The  Interface  State  Column  indicates  that 
pressure  gauge  becomes  part  of  a  set  named  selected  and  also  another  set  named 
activated  at  ^s  point.  I^ally,  in  the  second  User  Action  cell,  the  mouse  button  is 
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released  In  the  second  example,  the  Non-Mainline  Action  column  indicates  those 

user  actions  that  can  be  performed  that  are  not  directly  related  to  the  primary  task, 
here  Select  Detector. 


These  examples  show  that  the  user  pressing  the  mouse  button  (Mv)  creates  different 
results  for  these  two  tasks.  In  the  case  of  pressure  gauge  buttons,  selection  and 
activation  both  occur  as  a  result  of  the  user  pressing  the  mouse  button.  However,  in 
the  case  of  detector  buttons,  selection  occurs  as  the  result  of  the  user  pressing  the 
mouse  and  activation  occurs  as  a  result  of  the  user  releasing  the  mouse.  While  this  is  a 
simplistic  example,  all  these  little  inconsistencies  may  combine  to  confuse  a  user  and 
reduce  productivity.  In  the  process  of  writing  this  description  by  carefully 
performing  each  possible  task  in  the  EKDIS,  several  similar  inconsistencies  were 
uncovered.  This  Hnding  reinforced  our  previous  findings  that  the  UAN  provides 
inherent  consistency  checking  at  the  articulation  level  through  the  attempt  to 
combine  similar  user  actions  and  tasks  into  macros. 


Eiqploring  Alternative  Interaction  Techniques 

One  of  the  purposes  of  this  visit,  as  noted  above,  was  to  use  UAN  to  describe  a  variety  of 
unique  interaction  techniques  to  evaluate  the  notation  for  completeness.  NRL  is  a 
perfect  setting  for  this  since  much  of  the  work  taking  place  centers  around 
alternative  interaction  techniques  such  as  the  boom,  egocentric  projection,  and  eye 
gaze  technology. 

The  first  interaction  technique  to  be  examined  was  egocentric  projection.  This  system 
allows  the  user  to  control  their  view  of  objects  on  the  screen  in  three  dimensions  by 
merely  moving  their  head.  If  they  move  their  head  closer  to  the  screen,  the  image  on 
the  screen  is  magnified.  If  they  move  their  head  farther  from  the  screen,  the  image 
on  the  screen  is  reduced  in  size.  Further,  the  user  can  pan  up  and  down  or  left  and 
right  on  the  screen  by  moving  their  head  in  the  direction  in  which  they  wish  the 
screen  to  pan.  Currently,  there  is  no  capability  to  select  objects  in  this  technique. 
This  is  important  since  it  ^eatly  reduces  the  vocabulary  for  this  device  by  eliminating 
selection,  dragging,  and  activation. 

In  writing  the  UAN  description  of  this  task,  it  was  difficult  to  decide  whether  the  basic 
use  ci  this  device  was  made  up  of  one  task  (e.g.,  use  device)  or  two  tasks  (e.g.,  pan  and 
zoom)  combined  to  form  one  task.  Originally,  we  wrote  it  as  two  tasks.  However,  after 
discussions  with  the  developer  of  the  system  and  several  other  researchers,  it  became 
apparent  that  fix>m  a  user  perspective,  this  should  be  one  task.  This  is  because  a  user 
does  not  think  about  moving  in  the  (x,y)  plane  separately  fi’om  the  z  axis  when 
manipulating  a  3-0  image  on  the  screen.  The  user  will  move  as  directly  as  possible  to 
the  point  in  three-space  that  accomplishes  their  intended  purpose,  llius  the  task  of 
using  the  egocentric  projection  technique  would  be  written  as  follows: 


Tadu  use  esocentric  projection 

Arena:  simulator 

User  Action 

Feedback/ 

Presentation 

Interface  State 

The  second  interaction  technique  to  be  examined  was  the  Fake  Space  boom.  The  boom 
is  a  virtual  reality  device  which  allows  a  user  to  scan  in  any  direction  by  turning  their 
head  and  the  mask  of  the  boom  in  that  direction.  The  user  may  move  in  any  direction 
by  either  moving  the  boom  in  that  direction  for  small  movements  or  by  using  “fly" 
buttons-one  on  either  handle-to  move  quickly  forward  or  backward.  As  with 
egocentric  projection,  selection  is  not  implemented  with  this  technique.  Thus  the 
vocabulary  for  this  device  is  relatively  small. 

Again,  as  with  egocentric  projection,  the  difficulty  in  representing  this  technique  in 
UAN  arose  from  the  question  of  whether  it  should  be  represented  by  multiple  tasks  or 
by  one  task.  On  the  surface,  it  would  appear  that  use  of  this  technique  falls  into  one  of 
three  tasks;  panning,  walking,  or  flying.  In  fact  our  first  representation  of  this  task 
was  made  up  of  three  tasks.  However,  again  after  discussions  with  other  researchers 
and  users  of  the  technique,  it  became  apparent  that  this  was  not  the  case.  As  with 
egocentric  projection,  the  user  will  merely  do  whatever  is  necessary  to  move  from 
where  they  are  now  to  the  point  in  three-space  that  accomplishes  their  purpose.  Of 
course,  with  the  boom,  it  is  not  only  the  position  of  the  view  within  the  three-space 
that  is  important,  but  also  the  orientation  of  the  view.  Therefore,  representation  of  the 
task  of  using  the  boom  would  be  written  in  UAN  as  follows,  where  CONCURRENT  means 
perform  the  following  actions  simultaneously: 


Task:  use  boom 

Arena:  simulator 

User  Action 

Feedback/ 

Presentation 

Interface  State 

CONCURRENT(~(x,y,z), 

orient(a,b,c)) 

redisplay  view  flrom 
(x,y,z)  with 
orientation  (a.b.c) 

The  third  interaction  technique,  eye  gaze,  resulted  in  a  slightly  different  description. 
Y/ith  this  technique,  a  user  is  able  to  move  the  cursor  on  the  screen  by  looking  at  the 
object  or  location  on  the  screen  where  they  wish  the  cursor  to  go.  Objects  are  selected 
if  the  cursor  is  within  their  context.  If  the  user  holds  the  cursor  on  a  particular  object 
(Le.,  gazes)  for  a  preset  thne,  then  the  object  is  activated.  For  example,  if  the  user  holds 
their  gaze  and  thus  the  cursor  on  a  menu  heading  for  longer  than  a  preset  time  n, 
then  Ae  menu  will  be  activated.  Thus  the  UAN  description  of  the  basic  eye  gaze  task 
would  actually  be  two  tasks  written  as  follows: 


Task:  select  usina  eve  aaze(obiect) 

Arena:  simulator 

User  Action 

Feedback/ 

Presentation 

Interface  State 

object  icon! 

selected  »  object 

Task:  activate  using  eve  gaze  (object) 

Arena:  simulator 

User  Action 

Feedback/ 

Presentation 

Interface  State 

select  (object) 

activated  =  object 

Suggestions  for  Future  Work 

Other  alternative  interaction  techniques  and  input  devices,  such  as  voice  and  gestural 
interfaces,  were  discussed.  Several  basic  ideas  came  out  of  these  discussions.  First,  it 
appears  that  any  given  input  device  has  a  vocabulary.  This  means  that  even  though 
there  may  be  an  intinite  number  of  possible  physical  actions  a  user  may  do  with  a 
device,  there  are  a  limited  number  of  recognizable  actions  that  translate  into  a  user 
accomplishing  a  specific  task  with  an  interface.  This  vocabulary,  once  identified,  is 
easily  describable,  as  shown  by  the  boom  and  egocentric  projection  examples. 
However,  identifying  the  complete  vocabulary  of  a  given  device  may  not  be  a  trivial 
matter.  For  example,  there  are  a  number  of  actions  a  user  can  do  with  a  mouse,  such  as 
gestures  or  triple  click,  which  may  be  part  of  the  vocabulary  of  the  mouse  for  some 
applications  and  may  not  be  part  of  it  for  others.  The  idea  of  collecting  a  library  of 
UAN  descriptions  of  articulation-level  macros  and  tasks  for  the  vocabulary  of  known 
devices  is  one  that  is  interesting  for  future  work. 

Second,  there  was  a  concern  that  the  examples  shown  above  for  the  boom  and 
egocentric  projection  seemed  quite  simplistic  for  such  complicated  devices.  After 
funher  discussion,  it  became  apparent  that  while  these  devices  are  technically  quite 
complicated,  task  descriptions  for  them  are  simplistic  because  from  the  user's  view- 
whi(±  the  UAN  captures-they  are  very  simple  devices  to  operate. 

The  third  issue  centered  around  a  premise  underlying  the  UAN,  that  it  is  not  necessary 
or  useful  to  represent  physical  user  actions  that  result  in  virtual  user  actions  in  an 
interface.  For  example,  the  UAN  represents  moving  the  cursor  on  the  screen  but  does 
not  represent  the  user  moving  a  h^d  or  eye  or  whatever  physical  action  caused  the 
cursor  to  move.  A  number  of  possible  methods  of  representing  these  physical  actions 
were  discussed.  One  idea  was  to  extend  the  UAN  to  a  physical  layer  below  the 
articulation  level  where  a  user  actions  of  the  articulation  level  are  feedback  of  the 
physical  level.  While  this  approach  provides  an  intuitive  solution  and  provides  a 
certain  symmetry,  it  does  not  appear  to  be  sufficienL  The  problem  is  that  there  are  a 
very  large  number  of  possible  physical  actions  to  accomplish  a  single  virttial  action. 
Thus  this  physical  level,  written  in  UAN  or  any  similar  notation,  would  be 
prohibitively  large.  A  more  practical  solution  is  to  create  a  library  of  interaction 
devices,  their  associated  vocabulary,  and  physical  movements  that  accomplish  the 
actions  in  the  vocabulary.  In  this  way,  time-motion  studies  could  provide  assessment 
tests  for  whether  an  individual  user  will  be  able  to  accomplish  a  given  task  with  a 
particular  device.  Hme-motion  studies  have  already  been  done  for  Hve  of  the  basic 
input  devices  available  today:  mouse,  trackball,  joystick,  tablet,  and  cursor  keys. 

The  fourth  area  of  discussion  centered  on  the  method  of  representing  continuous,  or 
seemingly  continuous,  activity-either  user  or  system-with  UAN.  Currently,  the  UAN 
employs  the  method  used  by  state  transition  diagrams  and  other  notations,  which  is  to 
represent  continuous  activity  as  an  iteration  of  discrete  activities.  While  this  is 
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somewhat  intellectually  unsatisfying  and  over-simplified,  it  appears  to  be  sufficient 
for  our  purposes  of  representation,  since  a  computer  models  continuous  activity  in  the 
same  way. 

Another  area  of  discussion  was  that  of  the  formality  or  informality  of  the  UAN 
notation.  The  concern  was  raised  that  for  use  in  a  technical  environment,  the  notation 
should  be  more  formal  and/or  more  structured-possibly  even  standardized-to  support 
consistent  communication  among  developers,  and  also  to  support  automated  ansdysis, 
tool  development,  etc.  However,  this  contradicts  our  previous  findings  among 
industrial  clients  who  have  actually  complained  that  the  UAN  is  already  too  formal  and 
that  they  would  prefer  a  more  natural  language  notation.  We  have  purposely  made  the 
UAN  completely  open  to  allow  its  users  to  modify  and  extend  it  to  meet  the  unique  needs 
of  their  particular  user  interface  development  environment.  We  encourage  them  to 
adopt  whatever  notational  style,  content,  and  conventions  they  prefer.  In  this  way,  if 
a  group  of  UAN  users  wishes  to  formalize  their  in-house  use  of  the  notation,  they  may 
do  so,  while  other  users  may  choose,  for  example,  to  substitute  words  for  symbols  to  get 
closer  to  natural  language.  The  issue  of  standardization  versus  open  notation  will 
continue  to  be  investigated. 

The  final  area  of  discussion,  related  to  several  of  the  previous  ones,  is  developing  a 
case-based  “library"  of  UAN  descriptions.  Such  a  set  of  UAN  “idioms"  or  “behavioral 
widgets"  would  particularly  help  address  vocabulary  issue  and  standardization  issues. 
This  would  greatly  facilitate  writing  UAN  descriptions. 

All  the  above  issues  could  be  fruitful  topics  for  further  collaborative  work  and 
technology  transfer  between  NRL  and  Virginia  Tech.  NRL  provides  unique 
opportunities  for  such  collaboration  because  of  its  collection  of  innovative  interaction 
techniques,  its  highly  skilled  researchers,  and  its  focus  on  technology  transfer  from 
academia  to  application. 
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APPENDIX  1 


Complete  UAN  Description  of 
the 

Damage  Control  Information  System 
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Level  1 
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Lovel2 
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Level  2 
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Level  3 
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Cfoep:  increcve'it/dscrsc'.ent  buttons 

E>«scriptk3n:  typkal  Macintosh  button  wifi*  an  trrow  on  tc^  tnd  bottom 

Hig^Jightir^g;  sdccted  numeric  item  Lncremeits  o?  decrenenta  depending  on  location  of  the  mouse  and  button  shows  inverse  videos.). 
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APPENDIX  2 


Most  Frequently  Used  UAN  Symbols 
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UAM  SYf^LS  FOR  TK£  USER  AOIOMS  COUJMW. 


V\/hat  ii 

Represmted 

UAN 

Symbols 

OiTtoi  movement 

Offset  context 

[XJ 

Cursor  movement 

-[XI 

Cursor  movement 

-l«.yl 

Cursor  movement 

Cursor  movement 

Cursor  movement 

-[x,y  in  A) 

Cursor  rrtovement 

-(Xin  Y] 

Cursor  movement 

[xi- 

Switch  operation 

V 

Switdi  operation 

A 

Switch  operation 

Xv 

Switch  operation 

X'" 

Switch  operaticn 

Xv^ 

String  value 

K"ebc“ 

String  value 

K(xy2) 

Grouping 

() 

Sequence 

AB 

Repetition 

A* 

Repedtien 

A‘ 

Rqtodfkin 

A“ 

Opttenality 

(A) 

Choice 

I  ,OR 

Repeating  choice 

(A  I  B)* 

Older  iiukpaxlence 

A  fr  B 

Ir^enruptibUity 

A  -  B 

Unintemqrtibiiity 

<A> 

Intcricavabillty 

A  -  B 

Concurrency 

A  JIB 

Waidng 

A  It  >  n)  B 

Meaning 


move  the  cursor 

the  context  of  obfect  X,  the  "fumdle"  by  which  X  is 
muupulated 

move  cursor  into  context  of  object  X 

move  cursor  to  (arbitrary)  point  x,y 

move  cursor  to  lero  or  more  (arbitrary)  points  x,y 

move  cursor  to  spec^  point  x',y' 

move  cursor  to  (arbitrary)  point  within  object  A 

Btove  to  object  X  within  object  Y 

move  cursor  out  of  context  of  object  X 

depress 

rcJiiuise 

depress  button,  key,  or  switch  X 
release  button,  key,  or  switch  X 
idiom  for  clicking  buttort,  key,  or  switch  X 
enter  literal  string,  abc,  via  dievice  K 
enter  value  for  variable  xyz  via  device  K 
gtoupirtg  mechanism 

tasks  A  aivl  B  are  perfonrted  in  order  left  to  right,  or 
top  to  bottom 

taf-k  A  is  performed  zero  or  more  tintos 
task  A  is  performed  otw  or  more  times 
«a*v  A  is  performed  exactly  n  tintcs 
evcioaed  r»«k  is  opdonal  (task  A  is  performed  zero 
or  one  time) 

choice  of  (used  to  show  alternative  ways  to 
perform  a  task) 

cnoice  of  A  or  B  is  performed  to  completion, 
followed  by  anodter  choice  of  A  or  B,  etc. 

A  and  B  are  order  indcpeiulent  (order  of  dteir 
performance  is  immstetial) 

A  can  mtemqrt  task  B 
task  A  cannot  be  mterrupted 

pctformaiKC  of  tasks  A  and  B  can  be  interleaved  in  time 
task  A  artd  B  can  be  performed  simultaneously 
HrtJr  B  performed  after  a  delay  of  nwre  than  n  unia 
cf  Cinte  toUowing  task  A  _ _______ 


SYMBOIS  US  MTOFAS  FEZDBACK  COtJUMli 


WItttis 


UAN 

Symbols 


Meaning 


Localfon 

Locatkai 

Loodkm 

Display 

Blue 

Rfldfoplay 

Outline 

Dnnins 

Sidrbettwnding 

hr  all 


ji 

©x',/ 

@K 

©x',y'inX 

dfo|^y(X) 

escs«(X) 

tcdiaplay(X) 

outline(X) 

X>- 

x»  - 

V 


highlight  object 
unMghlight  object 

same  as  I,  but  use  a  different  highlight 
at  point  x‘,y’  (e.g,  to  display  X) 
at  object  X 

at  pobA  x',y'  in  ol^ect  X 
display  cl^^X 
cfflw  oofici 

erase  X  aitd  dl^lay  X  again  (in  new  locadon) 
outline  of  object  X 

closet  X  feOowa  (is  dragged  by)  cursor 
ot^ect  X  is  rubber-banded  as  its  follows  cursor 
for  fill  (eg.,  Vkona) 
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